1. Field
The disclosure relates generally to managing a multi-version database and more specifically to reducing database locking contention using multi-version data record concurrency control within the multi-version database.
2. Description of the Related Art
A multi-version database stores both current data records and historical data records in rows of a relational data table. The rows are typically annotated with timestamps representing the time period during which a row is valid or was valid. In a multi-version database system, new data records do not physically replace old ones. Instead, a new version of a data record is generated, which becomes visible to other transactions at commit time. Conceptually, many rows for a data record may exist, each row corresponding to a state of the multi-version database at some point in time. Older versions of data records may be garbage-collected as the need for the older versions diminishes, in order to reclaim space for new data records.
In a multi-version database, updates and deletions of data records require appending a new data record into the data table rather than performing in-place updates. These operations incur non-negligible performance overhead when multiple indexes on the data table exist and the record changes need to be propagated to these indexes. In a conventional multi-version database, performing a delete operation on a data record requires marking of the row's entry in each of the existing indexes. Any update that changes only one attribute of a data record causes a new version of the row, which needs to be propagated to all of the existing indexes. Hence, index updates will be unavoidable for these operations.